NOM¶

xinetd.conf - Fichier de configuration du démon amélioré des services Internet

DESCRIPTION¶

xinetd.conf est le fichier de configuration qui définit les services fournis par xinetd. Toutes les lignes dont le premier caractère est un « # » sont considérées comme des lignes de commentaires. Les lignes vides sont ignorées.

Le fichier contient des entrées de la forme :

service <nom_du_service>
{

<attribut> <assign_op> <valeur> <valeur> ...
...

}

L'opérateur d'assignation, assign_op, peut être l'un des suivants « = », « += », « -= ». La majorité des attributs ne supporte que l'opérateur d'assignation simple, « = ». Les attributs dont la valeur est un ensemble de valeurs supportent tous les opérateurs d'assignation. Pour de tels attributs, « += » signifie ajouter une valeur à l'ensemble des valeurs et « -= » signifie supprimer une valeur de l'ensemble des valeurs. Une liste de ces attributs sera donnée après que tous ces attributs aient été décrits.

Chaque entrée définit un service identifié par nom_du_service. Voici une liste des attributs disponibles :

id

Cet attribut est utilisé pour identifier de façon exclusive un service. Ceci est important, car il y a des services qui peuvent utiliser plusieurs protocoles et qui doivent être décrit avec des entrées différentes dans le fichier de configuration. Par défaut, l'identificateur du service porte le nom du service.

type

N'importe quelle combinaison des valeurs suivantes peut être utilisée :

flags

N'importe quelle combinaison des flags suivants peut être utilisée :

disable

ce flag est de type booléen « yes » ou « no ». Ceci indique si le service est désactivé et ne doit pas démarrer ou non. Voir la description du flag DISABLE.

socket_type

les valeurs possibles pour cet attribut sont :

protocol

détermine quel est le protocole employé par le service. Le protocole doit être présent dans le fichier /etc/protocols. Si cet attribut n'est pas défini, le protocole par défaut utilisé par le service sera utilisé.

wait

Cet attribut détermine si le service est de type mono-thread ou multi-thread. Si la valeur est yes le service est de type mono-thread ; cela signifie que xinetd démarrera le serveur et ne prendra plus en charge aucune requêtes pour ce service jusqu'à l'arrêt du serveur. Si la valeur de l'attribut est no, le service est de type multi-thread et xinetd continuera à prendre en charge les requêtes pour ce service.

user

détermine l'uid pour le processus serveur. L'utilisateur doit exister dans le fichier /etc/passwd. Cet attribut est sans effet si xinetd n'a pas été démarré sous l'uid du super-utilisateur.

group

détermine le gid pour le processus serveur. Le groupe doit exister dans le fichier /etc/group. Si le groupe n'est pas spécifié, le groupe de l'utilisateur user sera utilisé (récupéré dans le fichier /etc/passwd). Cet attribut est sans effet si xinetd n'a pas été démarré sous l'uid du super-utilisateur.

instances

détermine le nombre de serveurs qui peuvent être actifs simultanément pour un service (par défaut il n'y a pas de limite). La valeur de cet attribut peut être soit un nombre, soit UNLIMITED ce qui signifie qu'il n'y a aucune limite.

nice

détermine la priorité du serveur. La valeur est un nombre (qui peut être négatif) ; voyez le man de nice(3) pour plus d'information.

server

détermine le programme à exécuter pour ce service.

server_args

détermine les arguments passés au serveur. Contrairement à inetd, le nom du serveur ne doit pas se trouver dans l'attribut server_args.

only_from

détermine quels sont les hôtes autorisés à accéder au service. Sa valeur est une liste d'adresses IP qui peuvent être spécifiées par n'importe laquelle des combinaisons suivantes :

Spécifier cet attribut sans une valeur, rend le service indisponible pour tous

no_access

détermine quels ont les hôtes pour lesquels un service particulier n'est pas disponible. Sa valeur peut être spécifiée de la même façon que pour l'attribut only_from. Ces deux attributs déterminent le contrôle d'accès des hôtes effectué par xinetd. Si aucun des deux attributs n'est spécifié pour un service, le service est disponible pour n'importe quel hôte. Si les deux sont spécifiés pour un service celui qui a la meilleure correspondance pour l'hôte distant, détermine si le service est disponible pour cet hôte. (par exemple, si only_from contient 128.138.209.0 et que no_access contient 128.138.209.10 alors l'hôte avec l'adresse 128.138.209.10 ne peut pas accéder au service).

access_times

détermine l'intervalle de temps pendant lequel le service est disponible. Un intervalle de temps est de la forme heure:minute-heure:minute (les connexions seront acceptées durant un intervalle de temps). Les heures vont de 0 à 23 et les minutes de 0 à 59.

log_type

détermine où seront envoyés les logs de sortie. Il y a deux formats :

log_on_success

détermine quelles sont les informations logguées quand le serveur est démarré et quand il est arrêté (l'identificateur du service est toujours présent dans la ligne de log). N'importe quelle combinaison des valeurs suivantes peut être spécifiée :

log_on_failure

détermine quelles sont les informations logguées quand un serveur ne peut démarrer (soit par un manque de ressources système, soit à cause des restrictions d'accès). L'identificateur du service est toujours loggué ainsi que que la raison de la panne. N'importe quelle combinaison des valeurs suivantes peut être spécifiée :

rpc_version

détermine la version RPC pour un service RPC. La version peut être un nombre simple ou une plage de la forme chiffre-chiffre.

rpc_number

détermine le numéro pour un service RPC NON LISTÉ (cet attribut est ignoré si le service est connu).

env

La valeur de cet attribut est une liste de chaînes de caractères de la forme « nom=valeur ». Ces chaînes seront ajoutées aux variables d'environnement avant de démarrer un serveur (par conséquent l'environnement du serveur sera constitué de l'environnement de xinetd plus les chaînes spécifiées).

passenv

La valeur de cet attribut est une liste de variables d'environnement de l'environnement de xinetd qui sera passée au serveur. Si la liste est vide cela signifie qu'aucune variable n'est passée au serveur, excepté celles passées avec l'attribut env. (notez que vous pouvez utiliser cet attribut en même temps que l'attribut env pour spécifier précisément quels attributs seront passés au serveur).

port

détermine le port du service. Si cet attribut est spécifié pour un service déjà listé dans le fichier /etc/services, il doit avoir le même numéro de port que celui listé dans ce fichier.

redirect

Autorise un service tcp à être redirigé vers une autre machine. Quand xinetd reçoit une connexion tcp sur ce port, il lance un processus qui établit une connexion vers l'hôte et le numéro de port spécifié, et transmet toute les données entre les deux machines. Cette option est très utile quand votre réseau interne n'est pas visible depuis l'extérieur. La syntaxe est : redirect = (adresse ip) (port). Vous pouvez aussi utiliser un nom de machine à la place de l'adresse IP dans ce champ. La résolution du nom n'est effectuée qu'une seule fois, lorsque xinetd est lancé, et la première adresse IP renvoyée est celle qui sera utilisée, jusqu'à ce que xinetd soit redémarré. L'attribut « server » n'est pas requis lorsque cette option est spécifiée. Si l'attribut « server » est spécifié, il est est prioritaire.

bind

Autorise un service à être limité à une interface réseau spécifique sur la machine. Cela signifie que vous pouvez avoir un serveur telnet à l'écoute sur une interface sécurisée du réseau local, mais pas sur l'interface du réseau externe. Ou bien un port sur une interface peut effectuer une action, tandis que le même port sur une autre interface peut faire quelque chose de complètement différent. La syntaxe est : bind = (adresse ip de l'interface).

interface

Synonyme de bind.

banner

Prend le nom du fichier dont le contenu sera affiché sur l'hôte distant lorsque la connexion à ce service sera établie. Cette bannière est affichée sans tenir compte du contrôle d'accès. Elle doit toujours être affichée lorsqu'une connexion est faite.

banner_success

Prend le nom du fichier dont le contenu sera affiché sur l'hôte distant lorsque une connexion à ce service est autorisé. Cette bannière est affichée dès que l'accès au service est permis.

banner_fail

Prend le nom du fichier dont le contenu sera affiché sur l'hôte distant lorsque une connexion à ce service est refusée. Cette bannière est affichée dès que l'accès au service est refusé. Cela est utile pour informer les utilisateurs qu'ils sont en train de faire quelque chose qui n'est pas autorisé, et qu'il ne doivent pas continuer.

per_source

Prend un entier ou un « UNLIMITED » comme argument. Ce paramètre spécifie le nombre maximum d'instances autorisées pour ce service par adresse IP source. Cela peut aussi être spécifié dans la section defaults.

cps

Limite le taux de connexions entrantes. Prends deux arguments. Le premier argument est le nombre de connexions par seconde à prendre en charge. Si le taux de connexions est plus élevé que celui précisé, le service sera désactivé temporairement. Le deuxième argument est le nombre de secondes qu'il faut attendre pour rétablir le service après sa désactivation.

max_load

Reçoit un nombre décimal qui représente la charge maximale que le service peut accepter, une fois ce chiffre atteint, aucune nouvelle connexion ne sera acceptée. Par exemple : 2 ou 2.5. Le service n'acceptera plus de connexions lorsque cette charge sera atteinte. Il représente la charge moyenne durant une minute. Cette caractéristique est dépendante du système d'exploitation, et n'est pour l'instant supportée que par Linux et Solaris.

groups

Cette option peut être définie à « yes » ou « no ». Si l'attribut de groupe est positionné à « yes », alors le serveur est lancé avec l'accès aux groupes dont l'UID effectif du serveur à accès. Si l'attribut de groupe est positionné à « no », alors le serveur fonctionnera sans groupe supplémentaire. Cet attribut doit être positionné à « yes » pour beaucoup de systèmes BSD. Cet attribut peut aussi être activé dans la section defaults.

umask

Positionne le umask pour le service. Une valeur octale est attendue. Cette option peut être activée dans la section « defaults » pour choisir un umask pour l'ensemble des services. xinetd positionne son propre umask avec la valeur précédente de l'umask et un OU logique avec 022. C'est cette valeur de umask sera transmise à tous les processus enfants si l'option umask n'est pas utilisée.

enabled

Prend une liste des noms des services à activer. Cela activera seulement les services qui seront dans la liste d'arguments de cet attribut ; les autres seront désactivés. Remarquez que l'attribut « disable » et le flag « DISABLE » peuvent empêcher un service d'être activé, même si il est listé dans les arguments de cet attribut.

include

Prends un fichier de la forme « include /etc/xinetd/service ». Le fichier est alors parcouru comme un nouveau fichier de configuration. Ce n'est pas la même chose que si le contenu du fichier était inclus dans xinetd.conf à l'emplacement de la directive include. Le fichier inclus doit être au même format que xinetd.conf. Cela ne doit pas être spécifié à l'intérieur d'un service. Ce doit être spécifié en dehors de la déclaration d'un service.

includedir

Prends un nom de répertoire de la forme « includedir /etc/xinetd.d ». Chaque fichier à l'intérieur de ce répertoire, mis à part les fichiers contenant un point (« . ») ou se terminant par un tilde (« ~ »), seront parcourus comme des fichiers de configuration de xinetd. Les fichiers seront parcourus par ordre alphabétique en se référant à la variable d'environnement C locale. Cela vous permet de spécifier un services par fichier à l'intérieur de ce répertoire. La directive includedir ne doit pas être spécifiée à l'intérieur d'une déclaration de service.

rlimit_as

Positionne la limite des ressources de l'espace d'adressage pour le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d'octets de cette limite (K ou M peuvent être utilisés pour spécifier des kilooctets/megaoctets) soit « UNLIMITED ». À cause de la manière dont la fonction malloc de la libc de Linux est implémentée, il est plus efficace d'utiliser cette limite que celles de rlimit_data, rlimit_rss et rlimit_stack. Cette limite des ressources n'est implémentée que sur les systèmes Linux.

rlimit_cpu

Positionne le nombre maximum de secondes utilisées par le CPU pour le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre de secondes utilisées par le CPU, soit « UNLIMITED ».

rlimit_data

Positionne la limite maximale pour la taille de données utilisées par le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d'octets, soit « UNLIMITED ».

rlimit_rss

Positionne la limite de la taille mémoire résidante pour le service. Si cette limite est basse, le processus aura tendance à swapper sur le disque dur si la mémoire libre est faible. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d'octets, soit « UNLIMITED ».

rlimit_stack

Positionne la taille maximale de la pile pour le service. Un paramètre est obligatoire, qui est soit un entier positif représentant le nombre d'octets, soit « UNLIMITED ».

deny_time

Paramètre l'intervalle de temps durant lequel l'accès à tous les services pour toutes les adresses IP est refusé à quelqu'un dont la variable SENSOR à été positionnée à off. L'unité de temps est la minute. Les options valides sont : FOREVER, NEVER, ou une valeur numérique. FOREVER fait que l'adresse IP concernée n'est pas purgée tant que xinetd n'est pas redémarré. NEVER fait que l'adresse IP est juste logguée. Un valeur de temps typique est 60 minutes. Cela doit arrêter la plupart des attaques par déni de service (DOS attacks ) et autorise les adresses IP venant d'un pool d'adresses à être recyclées pour des besoins légitimes. Cette option doit être utilisée avec le flag SENSOR.

Il n'est pas nécessaire de spécifier tous les attributs précités pour chaque service. Les attributs nécessaires pour un service sont :

Les attributs suivants supportent tous les opérateurs d'assignation :

Ces attributs peuvent apparaître plus d'un fois pour un même service. Les attributs restants ne supportent que l'opérateur « = » et ne peuvent apparaître plus d'une fois pour un service.

Le fichier de configuration peut aussi contenir une seule entrée par défaut qui a la forme

defaults
{

<attribut> = <valeur> <valeur> ...
...

}

Cette entrée fournit des valeurs d'attribut par défaut pour les service qui ne spécifient pas ces attributs. Les attribut par défaut possibles sont :

Les attributs avec un effet cumulatif peuvent être spécifiés plusieurs fois avec les valeurs spécifiées qui s'accumulent à chaque fois (par exemple « = » fait la même chose que « += »). À l'exception de disabled ils ont tous la même signification que si ils étaient spécifiés pour un service. disabled détermine les services qui sont désactivés même si ils sont appelés dans le fichier de configuration. Cela permet une reconfiguration rapide en spécifiant les services désactivés avec l'attribut disabled au lieu de tous les commenter. La valeur de cet attribut est une liste d'identificateurs séparés par des espaces. enabled a les mêmes propriétés que l'attribut disabled. La différence étant que enabled est une liste de services qu'il faut activer. Si enabled est spécifié, il n'y a que les services spécifiés qui sont disponibles. Si enabled n'est pas spécifié, tous les services sont supposés être activés, excepté ceux qui sont listé par l'attribut disabled.

SERVICES INTERNES¶

xinetd fournit en interne les services suivants (à la fois ceux de type stream et ceux de type datagramme) : echo, time, daytime, chargen, et discard. Ces services ont les mêmes règles d'accès que les autres services, sauf pour ceux qui ne demandent pas à xinetd de forker un nouveau processus pour eux. Ceux-ci (time, daytime, et le echo de type datagram, chargen, et discard) n'ont aucune limitations de leur nombre d' instances.

xinetd fournit aussi deux services internes NON-LISTÉS de type stream : servers et services. Le premier liste les informations concernant les serveurs qui tournent, alors que le dernier fournit une liste des services actuellement actifs. Il y a un service par ligne et chaque ligne contient le nom du service, le protocole (par exemple « tcp ») et le numéro de port.

Il existe maintenant une interface d'administration qui est un service interne. Le nom du service « xadmin » est réservé, et sera toujours un service interne. Vous devez spécifier un numéro de port pour ce service, et probablement un contrôle d'accès basé sur l'adresse IP, car à l'heure ou nous écrivons ces lignes, il n'y a aucune protection par mot de passe. Vous pouvez faire un telnet sur ce port et demander des informations à xinetd.

NOTES¶

1.

Les attributs des services suivants ne peuvent être changés lors d'une reconfiguration : socket_type, wait, protocol, type.

2.

Lorsque les attributs only_from et no_access ne sont pas spécifiés pour un service (que ce soit directement ou par l'option defaults) la vérification d'adresse est considérée comme bonne (c'est à dire que l'accès ne sera pas refusé).

3.

La vérification d'adresse est basée sur l'adresse IP de la machine distante et non pas sur son nom de domaine. Cela est fait pour éviter la résolution de nom de la machine distante, qui peut prendre beaucoup de temps (comme xinetd est single-threaded, pendant la résolution de nom le démon ne pourrait pas accepter d'autres requêtes, jusqu'à ce que la résolution de nom soit terminée). Le mauvais coté de cette approche est que si l'adresse IP d'une machine distante change, alors il est possible que l'accès à cette machine soit refusé jusqu'à ce que xinetd soit reconfiguré. L'accès sera refusé ou non, suivant que la nouvelle adresse IP sera parmi celle autorisées ou non. Par exemple si l'adresse IP d'un hôte passe de 1.2.3.4 à 1.2.3.5 et que only_from spécifie 1.2.3.0 alors l'accès ne sera pas refusé.

4.

Si l'option de log USERID est spécifiée et que la machine distante, soit ne fait pas tourner un serveur d'identification, soit renvoie une réponse incorrecte, l'accès ne sera pas refusé à moins que le flag de service IDONLY soit utilisé.

5.

L'interception fonctionne en clonant un processus qui fait office de filtre entre la ou les machine(s) distante(s) et le serveur local. Cela a évidemment un impact sur les performances, il est donc de votre ressort d'établir un bon compromis entre la sécurité et les performances pour chacun des services. La table suivante montre le coût lié à l'interception. Le premier tableau montre le cout-par-datagramme en terme de temps pour un service de type UDP, utilisant diverses tailles de datagrammes. Pour les services de type TCP, nous avons mesuré la diminution de bande passante due à l'interception, pendant que nous envoyons une certaine quantité de données depuis le client vers le serveur (la perte de temps est la même que pour les services de type UDP, mais elle est « payée » seulement lors de la transmission du premier paquet de données ). Le montant de données est donné dans le tableau par appels_systèmexdata_envoyé_par_appel, c'est à dire chaque appel système envoyé(2) à transféré tant d'octets de données. La réduction de bande passante est donnée en terme d'octets par secondes et comme un pourcentage de bande passante lorsque l'interception n'est pas effectuée. Toute les mesures ont été effectuées sur une SparcStation IPC sous SunOS 4.1.

EXEMPLE¶

#
# Exemple de fichier de configuration pour xinetd
#
defaults
{

}
#
# Note 1 : l'attribut du protocole n'est pas requis
# Note 2 : l'attribut d'instances écrase l'attribut par défaut
#
service login
{

}
#
# Note 1 : l'attribut d'instances écrase l'attribut par défaut
# Note 2 : les flags log_on_success sont incrémentés
#
service shell
{

}
service ftp
{

}
# Limite les sessions telnet à 8 Méga octets de mémoire et un total de
# 20 secondes de temps CPU pour les processus fils.
service telnet
{

}
#
# Cette entrée et les suivantes spécifient des services internes. Comme
# il s'agit du même service utilisant un type de socket différent,
# l'attribut id est utilisé pour identifier chaque entrée de façon unique
#
service echo
{

}
service echo
{

}
service servers
{

}
#
# Exemple de service RPC
#
service rstatd
{

}
#
# Exemple de service non listé
#
service unlisted
{

}

VOIR AUSSI¶

xinetd(1L),

xinetd.log(5)

Postel J., Echo Protocol , RFC 862, May 1983

Postel J., Discard Protocol , RFC 863, May 1983

Postel J., Character Generator Protocol , RFC 864, May 1983

Postel J., Daytime Protocol , RFC 867, May 1983

Postel J., Harrenstien K., Time Protocol , RFC 868, May 1983

StJohns M., Identification Protocol , RFC 1413, February 1993

BUGS¶

Si le flag INTERCEPT n'est pas utilisé, le contrôle d'accès sur l'adresse de la machine distante n'est pas effectué lorsque wait est à yes et socket_type est stream.

Si le flag INTERCEPT n'est pas utilisé, le contrôle d'accès sur l'adresse de la machine distante pour les services ou
wait est à yes et socket_type est dgram est seulement effectué sur le premier paquet. Le serveur peut ensuite accepter des paquets en provenance de machines non autorisées dans la liste des contrôles d'accès. Cela peut arriver avec les services RPC

Il n'y a pas la possibilité de mettre un ESPACE dans une variable d'environnement.

Lorsque wait est à yes et socket_type est stream, la socket passée au serveur peut seulement accepter des connexions.

Le flag INTERCEPT n'est pas supporté pour les services internes ou les services multi-thread.

TRADUCTION¶

Christophe Donnier (Novembre 2001)